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ABSTRACT 


This report describes work conducted on Delivery Order 181 between October 1996 through 
June 1997. During this period software was written to: compute axial PSD’s from HDOS 
AXAF-I mirror surface maps; plot axial surface errors and compute PSD’s from HDOS “Big 8" 
axial scans; plot PSD’s from FITS format PSD files; plot band-limited RMS vs axial and 
azimuthal position for multiple PSD files; combine and organize PSD’s from multiple mirror 
surface measurements formatted as input to GRAZTRACE; modify GRAZTRACE to read FITS 
formatted PSD files; evaluate AXAF-I test results; improve and expand the capabilities of the GT 
x-ray mirror analysis package. During this period work began on a more user-friendly manual for 
the GT program, and improvements were made to the on-line help manual. 
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1. Introduction 


The work conducted during this contractual period is a direct continuation of D O No. 145 and 
part of an on-going effort that dates back to 1992. The general goal of the current work has been 
two-fold: a) improve the flow of data from HDOS measuring instruments to Marshall’s in-house 
x-ray analysis code GRAZTRACE; b) develop a more user friendly interface to GRAZTRACE. 
The purpose of the work was to enhance AXAF-I optical modeling as a predictive tool for both 
ground and space-borne environments. Of particular concern was providing an analytical tool to 
support the critical ground-based testing of AXAF-I. 

HDOS generated mountains of optical testing data from three main diagnostic tools These 
included roundness of the “barrel” optic as a function of axial position; axial figure profilometry; 
and surface roughness. The data formats and headers of these measurements had to be coupled to 
GRAZTRACE via interface software which permitted GRAZTRACE to “understand” and utilize 
the measurement data to predict image behavior. Developing the various interface softwares was 
difficult and tedious work requiring imaginative programming and attention to detail. 

A command mode version of GRAZTRACE was previously developed by Dr. Feng (CAO). This 
software was written to provide potential users with better access to GRAZTRACE This 
interface program is (called GT) contains a three letter command structure similar to that found in 
Code-V, one of the major commercial optical design and analysis packages. The reason for doing 
this was to allow optical engineers familiar with Code-V to feel more comfortable with the new 
X-ray analysis software. The user manual was formatted in a manner akin to that of Code-V 
showing the command syntax, synopsis, and options. (An on-line help manual was also provided 
and structured in a similar manner). However, Code-V is not used universally This means that an 
optical engineer reared on an alternate design code (such as Synopsis, ACCOS-V, ZEMAX, 
Super-OSLO, or GENII) would derive no benefit from this manual. In other words, the user- 
friendliness of GT was limited The goal of the revised manual was to expand the arena of 
potential users by providing enough background information so that the user could better 
understand and implement GT. 


2 . Axial PSD’s 

The work performed here involved modifying and testing the program “drinfsmp” The program 
“drinfsmp” is written in FORTRAN. The program reads HDOS surface map files (measured data), 
computes the surface deformation and scattering. The scattering is evaluated using the Power Spectral 
Density (PSD). 
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at Computing and Averaging PSPs 


The modified “drinfsmp.f” computes the PSD of each individual axial data set after low-frequency 
surface error has been removed. These individual data sets are then averaged over azimuths (or over 
a number of data sets measured at the same azimuthal angle). The averaged PSD data is regrouped 
to 1024 points or less. If the data points in the original PSD are greater than or equal to 1024, the 
regrouped data points will be 1024. If the original data points are less than 1024, the regrouped data 
points will be the same as the original data points. All of the above features were accomplished by 
adding additional commands to the main program “drinfsmp.f 7 . 

The averaged and regrouped PSD data can be displayed directly on the screen as PSD vs. spatial 
frequency, or saved as postscript file for making hardcopies. Users have the option of choosing either 
one or both. This feature was implemented by adding the subroutine “psdplot.f 7 to the main program. 

The PSD data and relevant parameters can also be saved to an output FITS file via the subroutine 
“wfits.f 7 (which was added to the main program). This file can also be used as an input file by other 
programs 

b) Enhance Graphics Capability: 

In order to make the software more user friendly, the graphics capability has been enhanced. The 
enhancement includes adding the labels and axis titles to each plot, and saving the plots as a postscript 
file. This was done by modifying the main program “drinfsmp.f 7 and each plot subroutines. 

c) Testing “drinfsmp 77 Program: 

The PSD computation of the “drinfsmp' 7 has been tested using two types of data. One was generated 
by Dr. Zissa using the Hanning window filter, the other was generated by HDOS using the Welch 
window filter. 

The data generated with Hanning window was applied to “drinfsmp” directly. Several bugs 
(including bugs in both the original code and modified portion) were found and corrected. The PSD 
generated by “drinfsmp 77 agrees with the PSD used to generate the test data. 

To test the data generated with the Welch window, The code “drinfsmp” was copied to a code 
“drinftest 77 . The latter was then modified to replace the Hanning window with the Welch window, 
and then used to compute the PSD following the HDOS practice. The PSD generated by “drinftest” 
agreed with the PSD generated via the HDOS method 
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3. Big-8 Scans 
a) Compute & Plot PSD : 

The software to write programs to plot axial surface errors and compute PSDs from the HDOS 
AXAF-I “Big 8” axial scans was completed. The software was tested against two known data sets 
in order to verify correct operation. All details of the test were documented and archived and may 
be found in the file venus:/export/home/Ihawkins/b8psd/testl/btestl .tar.gz. A brief summary of the 
test procedure is documented here. 

The executable software, filename “b8psd”, was used to process the “sen 1” files in the same manner 
as is indicated in the corresponding HDOS “psd 1” files (i.e. using the same cut points, removing the 
same number of polynomial terms and applying the same windowing function). However, the HDOS 
software for generating PSD data from “Big 8” scans employed a different method for setting the 
number of points to be used in calculating the Fast Fourier Transform (FFT). The result was that 
PSD data files generated by “b8psd” (psd.fits files) had a significantly different number of points than 
the corresponding PSD files generated by HDOS (psdl files). In order to facilitate a one-to-one 
comparison of PSD data, the number of points used to calculate the PSD for each of the two test 
files, in turn, was temporarily hard coded into “b8psd”. 

The test cases were run with “b8psd” in mode “-ib” (i.e. Interactive mode; send plots to both the 
screen and the PostScript file named plots.ps.) The PSD y-axis values were written out in ASCII 
format from the resulting “psd.fits’’ files (using the vfits utility) to files named “rawfileprefix.psd. ascii” 
for comparison with the “ypsd ascii” files which contain PSD y-axis values from HDOS PSD files. 

The plots.ps file mentioned above contains plots of the data at each stage of processing. There are 
seven plots (seperate PostScript pages) for each data file processed. The final plot is the PSD data 
In order to retain just the PSD plots for comparison with the HDOS PSD plots, the PostScript file 
was edited with the vi editor and the prolog and final plot (page) were written to a seperate file 
named “rawfileprefix psd.ps”. 

hi PSD Averages : 

The function of the program “psdavg” is to obtain the averaged PSD distribution from a number of 
PSD files processed from “Big 8” scan files This program also reads a number of PSD files listed 
in an input file list. Instead of integrating PSD over the spatial frequency range, this program 
averages PSD from all input files at each spatial frequency. Similar to “drinfsmp ", if the data points 
in PSD are greater than 1024 (default), the program will regroup them to 1024. The averaged PSD 
vs. spatial frequency will be plotted and saved as a FITS file with both axes in log scale. 
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This program provides user the following options: 


(a) Display the plot on the screen, or to save it as a postscript file, or both; 

(b) Select the azimuthal range to be averaged; 

(c) Change default output data points (instead of 1024). 

4. FITS PSDs & RMS 

a) “psdplot” : 

The program “psdplof ’ is a utility to plot the PSD data saved in FITS format regardless of how the 
data was obtained (e g. HDOS surface maps, WYKO, or Big8 scans). This program can take as 
many as 65536 data points (perhaps even more). The data is displayed as PSD vs. spatial frequency 
with both axes in log scale. The user has the option to display the plot on the screen, or to save it as 
a postscript file, or both. 

h) “prmsz” : 

The function of the program “prmsz’’ is to compute and plot the RMS surface roughness along the 
rotational axis of the surface (z). The program reads a number of PSD files (generated from WYKO 
data) listed in an input file list. Each input data file represents a PSD in a small z range. The RMS 
surface roughness is obtained as the integral of the PSD. The z range is averaged to define the z 
position of the computed RMS surface roughness Therefore, each data file contributes one data 
point with the coordinate (RMS, z). The plot consists of a number of data points in a fashion of RMS 
vs. z. 

This program provides user the following options: 

(a) Display the plot on the screen, or to save it as a postscript file, or both; 

(b) Select the range of z to be plotted; 

(c) Select the range of spatial frequency to be integrated. 


5. EEGRAZ Inputs and Modification 

EEGRAZ was modified to be able to read FITS format PSD files, however, this feature has yet to 
be tested. Dr. Zissa may have to test the modification since he is currently the only one who knows 
how to use EEGRAZ. 


5 



6. GT Debugs & Upgrades 

a) A problem with the ENE command (used to specify up to 15 distinct x-ray energy levels for 
evaluation) was fixed. The problem was that the algorithm used to check the index of the energy 
being specified was faulty. 

b) A problem which involved using the SAV, RES and PRE commands to read and write from and 
to multiple prescription files was fixed. The problem was that if a user REStored a prescription from 
an existing multi-prescription file and then SAVed it to a file with a new name, the newly created file 
became the current working file. However, the user was expecting the originally REStored file to 
remain the working file. Furthermore, existing code which would have detected the problem (when 
the user tried to read a subsequent prescription from what he assumed to be the original file but what 
was in reality the new file which contained one less prescription than the original file) contained a 
single error which prevented detection of this error condition. 

c) An upgrade was made to the GT source code which involved placing two labeled common block 
statements, / syscl/ and /cmdcl/, into “header” files syscl.h and cmdcl h, respectively. References 
to the respective common blocks in GT source code files were subsequently replaced with “include 
file” statements and the corresponding makerules file entries were made dependent on the proper 
header file. This upgrade allows the programmer to make a change in a single header file which will 
be automatically applied to all files which are dependent on the header file, rather than having to make 
the same change to multiple source code files containing the same common block. 


7. GT New Features 

The capability to read in ASCII EEGRAZ scattering distribution files was added to GT. Two distinct 
“definitions” can be made to describe scattering properties to be applied to mirror surfaces In each 
of the two definitions, up to five different scattering files (which more or less represent regions with 
different scattering properties) can be specified An upper and a lower z-axis limit must also be 
specified for each scattering file so that GT will know the range over which the scattering properties 
of that file are in effect. 

Three new commands are available in GT to set the parameters described above and to associate a 
surface in the mirror prescription with one of the scattering distributions: FSC, ZSC, and ISC. 

FSC is used to enter the names of the scattering distribution files and has the following syntax: FSC 
i j k (where i is an integer specifying one of the two scattering definitions, j is an integer specifying 
one of the five possible scattering file name storage locations, and k is a string (<= 80 characters) 
which is the name of the scattering file). The file names are stored in the new character*80 variable 
“ifsct(5,2)’\ 
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ZSC allows the user to set the z-axis limits over which the scattering distribution data from each file 
is to be applied and has the following syntax: ZSC i j k 1 (where i is an integer specifying one of the 
two scattering definitions, j is an integer specifying one of the five possible scattering files, k is an 
integer specifying either the lower ( 1) or upper (2) limit, and 1 is a double precision value which is the 
z-limit itself). The z-axis limits are stored in the new double precision variable “zslim(2,5,2)’\ 

Finally, ISC is used to associate a surface in the mirror prescription with one of the scattering 
definitions (i.e. ISC is used to tell GT to apply the characteristics of one of the scattering definitions 
to a particular surface) and it has the following syntax: ISC i j (where i is an integer specifying the 
number of the surface in question in the prescription and j is an integer specifying one of the two 
scattering definitions). This data is stored in the new integer*4 variable “iscat(50)'\ Any number of 
the surfaces in the prescription can be associated with either of the scattering definitions. 

There are also several other new variables which are used by the scattering feature. The two double 
precision array variables sadat( 100 1,5,2) and sedat( 100 1,5,2) are used to hold the scattering angle 
and encircled energy fraction data, respectively, for the five possible files of the two possible 
scattering definitions. In both cases, up to 1001 scattering angle and 1001 encircled energy values can 
be stored. Another new variable is the integer*4 array slen(5,2) which holds the number of scattering 
angle and encircled energy data pairs that are in each of the five possible files of the two possible 
scattering definitions. The character* 80 array variable scmnt(20) is used to read (and essentially 
discard) the comments from each of the EEGRAZ scattering files used. The integer*4 array isu(2 ) 
is used to indicate, upon execution of the random ray distribution trace, which of the two defined 
scattering definitions are to be applied to the current trace. The isu() array is set by cycling through 
the iscat() array and seeing if any of the surfaces are associated with one of the scattering definitions. 

If a surface is associated with scattering definition one, then element one of isu() is set to one. If a 
surface is associated with definition two, then element two of isu() is set to one. Otherwise, both 
elements of isu() are set to zero. 

This new scattering feature was subjected to a series of three tests. Each test was designed to check 
a particular aspect of the scattering capability The first test verified that the rays were being scattered 
only in the plane of reflection and that the rays were scattered consistent with the scattering 
distribution data file being used The second test verified that the net effect of applying a scattering 
distribution to both the parabola and the hyperbola is about the same as the effect of adding the two 
scattering distributions and applying the result to the hyperbola only. The third test verified that the 
feature properly handles multiple scattering regions within a single mirror. The scattering feature 
passed all three tests! The files relating to each of the three tests were archived together (tar-ed and 
gzip-ed) and may be found in zeus:/export/home/lhawkins/gt/scatest/*.gz. Each of the test archives 
includes a (FrameMaker) document describing the test, a (GT “ses") session file containing a list of 
commands that GT can read in and execute automatically via the “in" command, a “.txt" file which 
contains a (script) transcript of the GT session, all the input data files used for that test, and (Sun 
raster) snapshots of the resulting spot diagrams and point spread functions. 
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At present, the scattering capability is only available with the random ray distribution (WSP) and 
modified wheel spoke (WS2) traces Once the user has set all the ray trace parameters to his liking 
and then issues the GO command for the trace, two FORTRAN functions come into play. The first, 
ichkscQ, looks to see if either of the two scattering definitions has been set up by checking that any 
files given in ifsct() exist, that given z-axis limits (in zslim()) are such that lower limit < upperjimit, 
and that surfaces associated with a scattering definition are associated only with a definition that has 
actually been defined. The second function, irdsc(), reads in the data from the given scattering files 


8. User Manual 

The new user manual is not a revision of the old manual but a completely new edition. Its purpose 
is to allow neophytes to come up to speed quickly on the X-ray analysis package The only 
prerequisites are that the user be reasonably conversant with geometric optics and have some hands 
on experience with one of the commercially available optical design and analysis packages. The new 
manual provides more background information on X-ray telescopes to properly orient the reader into 
this somewhat esoteric area of optics. Comparisons are made between “barrel" X-ray telescopes and 
classical Cassegrain forms This is followed by a discussion of the mathematical description of barrel 
optics and how this is related to the more conventional forms for standard primary and secondary 
mirrors. The reader is then given a practical lesson about the mechanics of getting into (and out of) 
Graze. This is followed by a sample session in which the reader is taken step by step through an actual 
prescription entry. The commands used and their syntax are clearly explained. This section is 
supplemented with figures, charts, and appendices. The actual appearance of the Fortran name list 
is also included here. The reader is then shown how to check the prescription entry for functionality, 
i.e. will rays propagate through the system. If there is a mistake (or a change), the reader is shown 
how to use the Unix VI editor to alter the prescription. Again, all the commands used are clearly 
explained. 

Once a prescription is entered their are many analysis options which are organized into four general 
classes: ray trace; spot diagram; geometric point spread function; and geometric encircled energy The 
reader is then led through sample analysis sessions using the sample prescription entered earlier. The 
the commands and their sequence are demonstrated. [This portion of the manual must be 
supplemented with explanations of the various data outputs ] 

The reader is then shown how to transfer prescriptions and textfiles (of the analysis) to the remote 
site via FTP protocols This is necessary in order to get hardcopies of this information at the user’s 
site. [This section is incomplete and requires the procedures needed to generate hardcopies of the 
higher definition PV-Wave plots ] 

Two more extensive sections are to be added to the manual in the next phase These are a discussion 
and demonstration of the more advanced features of Graze (such as scattering), and a thorough 
introduction to CONVOLVE (which is the second major component of the Graze program) 
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9. On-Line Help 


a) The on-line help document was proofed for spelling and other errors and corrected as necessary. 
The help text segments for the individual commands were arranged in alphabetical order in the on-line 
help document 

b) A new method of updating the contents of the on-line help document was implemented. This new 
method places each help text segment for an individual command in its own text file, header text for 
the on-line help document is placed in its own file, a help text segment for the “?" command is placed 
in its own file and software (written in the PERL language) is utilized to construct the help document 
from these individual files and to automatically generate the command menu displayed to the user 
when the MEN command is entered. By generating the on-line help document in this manner, files 
containing individual help text segments for new commands may be added to those already in 
existence or existing files containing help text segments may be deleted, and the command menu will 
be automatically updated to reflect the changes. 

c) The subroutine which extracted text from the help document (named ‘hlp()’ and contained in 
source code file gthlp f) was modified such that it correctly displays the “Unknown command" phrase 
only when the user actually requests information on an unknown command and the commands menu 
is displayed in response. Otherwise, when the user simply asks to see the commands menu (via the 
MEN command), only the commands menu is displayed. 


10. IRAF Updates 

Updates for the IRAF /STSD AS/PROS image analysis software (patch level 2 for V2.10.4) and 
STSDAS (upgrade from 1.3.4 to 1.3.5) were available and obtained. On Friday 3 January 1997, Dr. 
James Carter, the Sun LAN System Administrator, was made aware of these updates and of their 
location in the directory /export/home/lhawkins/upgrades on computer venus.msfc.nasa.gov. 


11. Recommendations 

The CONVOLVE portion of the Graze software needs to be thoroughly exercised and debugged. No 
work has been done on this package since Dr Feng left CAO in 1995. CONVOLVE should also be 
incorporated into the new User Manual 

There are a number of improvements that should be made to Graze. First, prescription entry should 
follow conventional practice as found in standard commercial optical design and analysis codes. In 
particular, a spreadsheet format would be very user-friendly. Second, Graze should be able to convert 
from one prescription format to another Third, a graphical layout of the X-ray telescope should be 
incorporated along with the ability to trace individual rays through the system. This would also aid 
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the user as a diagnostic if their is an error in the prescription entry. Fourth, insertion of refractive 
indices should follow standard practice in which wavelengths (energies) and materials are specified 
and the code imports the correct values either from a look-up table or via a computation Fifth, the 
namelist should be replaced with a spreadsheet format and display only surfaces that are actually used. 
Sixth, commands should be grouped together in the on-line manual according to function, e g. all 
commands used in ray tracing should be found in one spot. Seventh, plots of encircled energy should 
be made available. Eighth, profile plots of the PSF should be made available. 
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